I think the tunnel lighting is quite well balanced, compared with the street lighting. Eric has set the lighting values by observation, we haven't gone so detailed as to set watts or lumens per light. But you can judge for yourself in this similar video done in the night.
EDIT: This video time is 03:14 on 4 May so the sky is not pitch dark.
There is no plan to release track editor in the near future. It's kind of a long term dream of something that may or may not happen. It would probably be a year or two or more of work like the vehicle mods. It's difficult to even imagine how it could work and the tracks would be distributed. It can't work like the vehicle mods. Anyway, I say this not to start a discussion about the track editor, that I cannot get involved in at this time, but to make sure people don't have false hopes. I simply added a few more features to help Eric use the track editor, as I have been doing for the last 25 years or so.
We have been working hard to get LFS ready to release. As many of you know from a recent report I have incorporated the current public tyre physics into the new development version. We call it the Retro model. It's the same tyre physics but now at 1000Hz and with a self-aligning torque component that slightly improves the force feedback. The idea is to get the new graphics out without further delaying the release to await the new tyre model that is still unfinished. We also described how Eric has expanded Kyoto massively, in a way that reminds you of Westhill but with more roads and with its own character. South City is all opened up too. Eric has continued to work on South City and Kyoto.
On my side, since the start of February, it has been mainly technical work finishing loose ends from the graphical update. In a roughly chronological order, areas covered in early February include:
Force feedback (appropriate filtering to prevent spikes)
ABS (updated for 1000Hz physics updates)
Thread-related crash related to moving subobjects
Retro model updated to use new system for friction on various surfaces
AI - some bugs were present after reinstating the Retro model
Then something I found interesting that can be illustrated with screenshots. As we now use physically based rendering and high dynamic range, the exposure (brightness of the final image) has become an issue, just as it is in real life. The difference between light areas and dark areas can be quite extreme. For example if we used an exposure level suitable for outside on a sunny day, then the inside of a tunnel or a multi-storey car park would look extremely dark, even with artificial lights switched on. The exposure must be turned up in these cases and we do that by analysing the output image for brightness and constantly updating the exposure.
So far, so good, but it's a tricky thing to get right. In a typical in-car view there is the dark car interior, the bright sky, and the landscape you actually want to see. It's not good enough to take the average of the whole scene and adjust the exposure based on that. Certain areas are of interest and they need to be exposed correctly.
Two examples that produce the wrong result if we consider the whole image.
1) In an open wheel racing car, you can see so much of the sky that the exposure is reduced and the image becomes too dark.
2) In a car with restricted view of the sky and a dark interior, a lot of the image is dark and so the exposure is turned up too high.
In the FERA, an approved mod by CarlosSainz55, the overall image is quite dark so the exposure ends up too high for the scenery.
In the FOX, the overall image is bright so the exposure ends up too low.
I used a trick, to identify the scenery using the alpha channel. When rendering the sky (each frame) and the interior of your own car in a driving view, I made sure the alpha channel of the pixels was set to zero (like transparency). The alpha channel was set to not transparent when drawing the scenery. So the image that is read to create the histogram for the exposure calculation, looks a bit like this. The magenta indicates where the alpha channel is left at zero.
Now the exposure calculation can consider only the parts that are not transparent. The exposure in driving views and trackside cameras is far more usable and stable, no longer a problem and you are mostly unaware of exposure changes as you drive around. Exposure adjustments as you move into and out of darker places seem appropriate and helpful.
One thing on my list was Z-buffer issues, that I had noticed at Kyoto and have always been around, usually seen as flickering of two nearby surfaces when it's not clear to the graphics card which pixels are nearer to the viewpoint. I noticed a post by Bokujishin in which he mentioned the "Reversed-Z" method that can produce more accurate Z-buffer results with no loss of performance. It is a now well known method in which the Z buffer values go from 0 in the distance, to 1 at the near clipping plane, instead of the other way round. I tried a quick experiment that did show an improved Z-buffer and then spent a couple of days working it in properly and solving the bugs and issues that inevitably come up when you make such a change in a complex program.
While doing that, I learned about the infinite far plane, a slight change to the projection matrix that allows us to avoid cutting off pixels that are rendered beyond a certain distance, with barely any loss of Z buffer accuracy (that had already been massively improved by the Reversed-Z system). This seemed to me almost like magic, but I tried it out and it worked perfectly. It's not the usual thing to find a little code that simplifies things and provides a better result without any downside.
One of the issues that had come up when first implementing the Reversed-Z system was fog. The haze effect that helps create a sense of depth by including more of the sky colour as objects are further away. It didn't work at all but by a simple change I was able to restore a Z value to the shaders and fix the fog. But as usual, one thing leads to another and I started to look at an ongoing problem we had, with fog glowing in dark places. The short explanation is that our graphics engine doesn't really know which parts of the air are in sun or shade, so even when the camera exposure is turned up (in a tunnel or car park) the fog effect still appears as if you are looking through lit air. And as the exposure is up by such extreme values, the fog level then appears to be incredibly bright and it looks quite bad. A previous workaround had attempted to alleviate the issue by starting the fog only after a certain distance. But it wasn't a good fix: in a long tunnel you could see a 'fog line' moving down the tunnel 120 metres in front. This can be seen in the South City Work in Progress video made by Victor in 2021 (time 2:40).
120 metres was OK for car parks but not for tunnels. In the end we came up with a solution based on a comparison between the image-based exposure, and the predicted exposure if you were outside (based on a simple calculation). Now when the image-based exposure is much higher than the predicted exposure, the fog is turned down and this seems to solve the problem in a way that it it no longer perceptible as an issue. Glowing fog in dark places is no longer, while haze in open areas is unaffected.
Continuing work after that included:
Shadows: a useful optimisation and slight improvement in accuracy
VR: post-processing is now available and final image submitted as 32-bit
VR: fix for Vive Pro 2 and any other headsets with non-square pixels
Interface: shaders to show some interface elements in greyscale
Public version: Compiled public version exe for the first time
Track editor: Some minor usability improvements
Still to do:
Support for pop-up headlights and handlebar mounted headlights
- these currently are undetected and do not cast a beam
Headlight analysis to allow smaller headlights to be drawn more brightly
- currently intensity is constant so a large headlight appears brighter
Take more steps towards building an actual public version
- currently exe runs but can only get as far as track selection screen
Some amount of adjustable weather, e.g. overcast sky
- not supporting clouds for this version but some options are possible
When will it be released?
We still can't say. There are several things on our lists and new things keep popping up, so it's not possible to give an estimate.
Eric has spent most of this year working on the Kyoto Ring environment and has expanded the driveable areas in a similar way to the Westhill track. In open configurations, you can drive around all the access roads and a new high speed karting track has been added.
To read about our progress and see some pictures of the Kyoto updates, visit the Kyoto Progress Report page.
I won't try to give all the answers. Each point you mention has been discussed many times before, at great length. You could try searching "Steam" for example.
I could make a few points though, before instantly unsubscribing from the thread as I don't want to start answering questions.
If financial growth was the aim, LFS would have been a completely different game. Eric and I founded Live for Speed with a deliberate aim to work on our own project, free from the pressures and issues of working in a larger company. Admittedly, we thought it would just be a project of a year or two, so that looks a bit different more than two decades later.
Live for Speed was on sale before Steam existed, so this is why we have our own payment system. Moving to Steam at this point would require restructuring our business and changing the code model. We would then be at the mercy of Steam ratings and in my opinion no longer "independent" (even if Steam is said to be for indie developers, such 'independent' developers are entirely dependent on Steam). This is too long a subject and I won't get involved. Many pages of forum text have been written about this already.
Regarding income, Eric and I believe that the ability to work on what we like, in our own time, is more important than a high income. If we wanted a high income, it would have been better to stay employed in larger companies. However, there was a period of relatively high income for some time starting with the release of S2. But over some years, sales dropped off gradually until income was eventually too low to live on. Some of this was caused by my change in life, moving house and bringing up two small children, which affected development. By the way, they are now 18 and 16 years old. Another cause for the eventual drop off was the well documented piracy, in which pirates were able to create a bigger active community than the legitimate one.
There were some boosts in that time, such as after important updates and the S3 license release. Although that only provided access to the laser scanned Rockingham track, people who upgraded to S3 did ensure continuing development. Eventually we were able to offer mods, which are not properly available in pirated systems.
How is all this relevant? Well, now we have enough income to pay our bills, so we can continue developing. We are still not interested in hiring more staff and moving into an office. I'm sure we are even less willing to do that now, after all these years working from home. There is no thought entering our minds to suddenly give up our entire work philosophy and try to get rich by running a company!
I don't want to get involved in a conversation but I'll say a few things then I'll unsubscribe from the thread.
I think Eric knows what I have been going through this year and probably didn't want to bother me with a progress report. And on the other hand he took on a pretty monumental task and so maybe he wanted it near complete before showing anything. I don't know really, I have not tried to discuss a progress report with him.
He did even more finishing of South City and has done repairs and updates on all the other tracks too. There's a curious thing about finishing things, as anyone knows who takes on big projects. The 'last few things' take a lot longer than expected.
But the biggest task he has been on for a long time, is Kyoto. Not only has the track had a lot of work done, but also the surrounding areas, it has had a treatment that could remind you of Westhill. I think he saw the potential and went for it. I'm sure you will be very happy to see a progress report about it when the time comes.
I just want to make it clear, I didn't start this year saying, "OK, now I will spend the first 7 months of the year doing web stuff that is out of my comfort zone". I didn't know at the start of the year that Victor would be more involved with his other job and gradually become more reluctant to work on Live for Speed.
The reality is I encountered a barrage of emergency situations (and growing problems) which needed attention. To list a few:
1) Mod hacks that were destroying the online experience
2) Mod submission spam that was overwhelming the reviewers
3) Bugs in mods system e.g. archives of deleted mods never being removed
4) Apparent leak of passwords that LFS users had given to a pirate website years ago
5) Bugs in hosting system causing crashes, slowdowns, etc.
6) DDoS attacks on web server
7) DDoS attacks on game servers
This is not a complete list, it's just off the top of my head. Each of these things took days or weeks to resolve, but at the start of each task I couldn't really delegate the task to community members. I just had to look into the issues and figure out what is going wrong, although the relevant systems were not written my me, and at the start of this year I really had no idea how it all worked. After figuring out the issue, either fix it (sometimes simple) or implement new systems as required (not usually simple).
I'm just explaining how one task after another has come my way, preventing me from doing whatever was planned, and this has sometimes been very frustrating, but it's not something that could be delegated to community members.
This new patch is intended to be a stable release. With all the fixes done, I hope that our systems may be stable for a while. This should let me focus on the tyre physics, to complete it to a good condition so it can possibly be released, along with some remaining graphical tasks. I can't give a time frame for this, as so far this year I've had almost no time to look into it. It seems like now I'm where I thought I would be at the start of January.
At least with all the delays on my side, Eric has had more time to do extra good work and keep up the detail. I have also learned a whole lot about PHP and SQL and understand how our web systems work. For example I was able to do this whole 0.7F update release alone without Victor's help.
In case the attackers might read a message, I will ask sincerely:
What is it that you really want?
We are two people - a programmer (me) and an artist (Eric) that try to provide a game for anyone in the world to play. Also, part time, Victor does a few things on the servers (he did a lot more in the past) and Geraldine helps with support emails. That's all. This is not a big company.
We are massively helped by community members including forum moderators, mod reviewers, creators of mods and software, race organisers, broadcasters and people simply participating in races and events online. People do this for a hobby, to have some fun, entertain and interact with others around the world.
In addition to the free demo, so that we can continue developing, we have a license, people can make a single payment and play for ever, getting free updates for life. What could be fairer than that? Other developers keep making a new version and charging you again for it. It's possible because we have such a small team, our business can get by on a low income, even though we try to provide servers around the world so everyone can play with a good ping.
Why do you seem to want to disrupt our players, who just want to have a bit of fun racing around? Who is it that you are trying to attack? Is it the developers, or our community? Are you on a side, and trying to attack the other side? Have we or our players harmed you in some way? I would love to know, because we really have no idea.
Live for Speed is a system that aims to bring the people of the world together to have fun with each other. A bit of peace in a world with too many conflicts. Can't we all just get along, wherever we are from, and whatever language we speak and whichever culture we have grown up in?
Can't we all just have a bit of fun, try to be one of the good things in the world?
Yuri, do you think maybe it is now time to move on?
You have made a career out of ripping off a tiny team of dedicated developers, to the point where we nearly had to close the business. This isn't a rich company that can afford such losses. We've recovered from that worst time now after making significant changes but you are still here trying to continue to extract whatever you can from us and harming the community.
Eric and I have dedicated our careers to working on this game for the enjoyment of thousands of people worldwide. I am sad that you are always there, engaging in illegal activities, scams and fraud, supplying malware to unsuspecting victims, making things difficult for so many people and damaging what we work so hard on.
Do you think, for your own sake, it may be time to move on and do something constructive with your life?
If you want a game with more developers, have a look around, there are plenty available.
More developers means more requirements for pay, which means more rushed updates and more following of the current trends. There is higher turnover of staff and more code with no remaining author, more confusion and more charges for customers. In the end the product is expensive to buy or use and then will be abandoned when it becomes impossible to maintain.
That is the result of the usual "more more more" way of running a business.
A lot of people don't understand that LFS is the way it is *BECAUSE* we develop it this way. It's doesn't just happen to be good somehow, despite our ridiculously stupid way of working.
By the way, LFS only exists because Eric and I didn't want to work in a large company any more. So it would be kind of strange to give that up and start trying to run a large company instead of actually doing what we want to do.
The NCL can only have an effect when used within the same smoothing group. In that case it will give a higher weighting to the triangles with the higher number. So it affects only the normals at the boundary between two normal contribution levels, within the same smoothing group. But across smoothing group boundaries, separate triangles do not contribute to the same normal anyway so then it has no effect.
But I wondered about the slight shading errors, and had a look in game and in editor. I tried "flat" view mode, because flat shading shows a good representation of the triangle normals, that produce the raw data for the vertex normals.
As you can see in flat shaded view, there is a sort of dent here (attached image). Because of how LFS works, that dent is the cause for the undesirable normals at that location.
I forgot to mention flat shaded mode. That is another thing that Eric uses a lot. I think that by moving vertices around a few mm here or there, the flat shaded model can display more consistent lighting and that will affect the vertex normals in a good way. I don't know if you can use the same thing in blender (I know blender supports non-triangle polygons so I don't know).
EDIT: I just remembered, sometimes triangle rotations can also have a quite a noticeable effect on the normals. I mean rotating two triangles within a quad (select 1 triangle, SHIFT+click the adjacent triangle). The LFS importer doesn't always make the best choice of triangle rotation when creating two triangles from a quad in the imported obj file.
I haven't seen the specific case you are talking about but there are some tricks you can use.
First to understand:
- the normals at a vertex are based on the directions of the connected triangles, within a smoothing group.
- the normal contributions are higher from the larger triangles meeting at that point.
You can adjust the normals in two main ways:
- extra triangles may sometimes be needed
- use "normal contribution level" (ncl)
I have a feeling that a lot of people don't know about normal contribution levels, although Eric uses them a lot. You can use it to increase the importance of some triangles, relative to others, regarding their contribution to normals.
Actually, triangles with ncl of zero will not affect the normal at all if there are triangles with a higher contribution level also connected to that point.
You can view and assign the ncl in a similar manner to smoothing groups.
I don't really want to lay down the law as such, but maybe a good guide would be our most recently updated car, the RB4 GT.
Eric is an artist and like most artists he would like to use more polygons, but he is also a game developer so tries to do what he can without being excessive with the numbers.
There are other ways to optimise models too, for example by using one texture page for several cutouts, within reason and when that is convenient (not possible for 'repeating' textures).
Note that "attachment" subobjects are merged into the main object so it's a good idea for attachments to share texture pages with the main object too (when convenient) as if they were part of the main object.
Also, most cars should have "Concealed driver" enabled. Driver not concealed is only needed for things like karts and bikes (when you can see the driver's body from a long distance away). ordinary road cars have concealed driver and this is a significant CPU saving. This setting does not affect the helmet, which is drawn anyway.
Eric and I are working on a project we love, the way we want to work. We work at home, on things we like to work on. It's a good life.
We don't work in an office, managing a team of artists and programmers and accountants and project managers etc.
The way we work earns less money but gives a better quality of life in our opinion although that might not be everyone else's ideal way to work.
If you are a victim of capitalism and you believe the purpose of life is to make the most money, then from your point of view we made wrong decisions, that's for sure.
If someone's opinion is that you should be able to work as closely as possible to the things you are interested in, then we made right decisions.
I'll say again, we make the game we want to make, the way we like to make it. If you like it, please race or play or whatever you want to do. If not, then go and do something else, that's fine. But just remember the developers are enjoying their work and this project is driven by many decisions other than maximising income.
I've added that to the RB4, and fixed the triangle errors in XRR / FO8 / XFR / FOX.
I'm nearly at the point to send Eric an update, and I've coded a setup height repair system as these development models have the model object centre correctly located at the lowest point of the model, instead of at rough ground level or whatever other random position they were in the old versions. The repair detects old setup and adjusts height according to a table of height adjustments for the official cars.
That's so all the existing setups will load correctly in the new version. No doubt they'll need an adjustment for the new physics but I think there's no harm in working from old setups.
I can't give any better estimate when the 1000 Hz update will be released. Eric is currently working on significant updates for Kyoto and I am trying to finish an intermediate semi-compatible release of the public version with improved mods support.
After that release I'll be trying to finish the new tyre physics and the plan is to release that with the new graphics, as both are in the separate development branch of LFS. I have no more information that that, at this time.
---
About the FF display, I seem to remember someone did a mockup of a way that a native FF display could work. Can anyone remember that, or does anyone have a good idea for it, how it could look, how it should be enabled? Should it be something like the display you can see when you click the small car button in Misc or Graphics options (a lateral graph moving up the screen).
Half the issue implementing something like this is the general design and the interface for it. Another significant problem with adding things to the screen are all the situations that can come up when trying to display the new feature at the same time as other things on the screen, so if you could help sort out the details that would be helpful.
I have a slight issue at the moment that whenever I try implementing some "simple feature that would be very useful" I end up spending several days or weeks sorting out all the repercussions that arise. So the thought of taking on yet another task is a bit nerve wracking right now.
By the way, in the development version I do have a simple "MAX FF" red text that comes up in the middle of the screen in the same place as the usual large text. It might be a bit too raw for a public release. Obviously this would be a lot simpler to implement than a graph. So that approach would avoid delays but I'm not sure how useful that would be, compared with the full graph display. Also would it need an option, like "Show FF clipping" NO / YES.
As you can see, particularly on the Editor Test Patch thread, I have made a huge number of improvements for the mod support. I find it a great thing that LFS is a way for people to be creative, and the mods system is a massive new part of that. It was very "new" indeed when released (basically a bunch of dev editors brushed up a bit) which is why there have been so many issues to sort out.
In the past months, while I have been doing these, Eric was at first finishing South City, which took a lot longer than he anticipated. Filling those holes is not easy, and he likes to fill them just as people would actually "fill the holes" when building a real city. I received an update recently and tested it, reported a bunch of issues and he fixed those. We find the completion level very good now, basically good enough for public testing when we can get the full version together. He is now working on the Kyoto improvements. As you may know from the official progress reports, that was never finished before Eric moved onto the South City, that turned into an epic development and massive expansion.
On my side, I'm trying to finish test patch things so that I can finally complete the tyre physics. In fact my current focus is on wheels, both in the development and public version. In the public version there should be a graphical update for wheels in the next few days, to go along with the many updates there have been for mods. Again, please read the test patch threads to know what I'm talking about.
There is also other work I do, that you never see, such as updates for the track editor. Suppose Eric is doing a task and finds he has to do something in a laborious or repetitive way and one of us thinks of a new editor function that could help him achieve certain tasks more quickly, then I always want to stop whatever else I was doing and work on the track editor for a few days.
I'm trying to get to an official release so my focus can then be entirely on the tyre physics in the development version. It has taken me much longer than expected to complete this round of test patches as there were so many unfinished things in the mods system. When I see creators, working hard and having to use workarounds for issues, I feel a great responsibility to get that issue sorted out.
Of course, the priorities I attach to various tasks, will not be the same as someone else's priority. We all have different priorities, so there's not a person in the world who could agree with all my choice of tasks to work on. But I must work on what I feel is important. Actually I find it a huge mental effort to complete these tasks, and that's why I need to follow the inspiration. Sometimes I'm awake at night working out how to do something, then experimenting and testing, it's a lot of work.
It takes a long time, but there is always progress.
I've received another South City update from Eric so did a few track editor updates that were relevant at this point. In the process I updated a few features from the public editor, so here they are.
Editor Test Patch D19:
Hotkey for "hide/unhide (un)selected" changed from X to H (like blender)
- small H button at top left to hide/show message history (old H function)
Left click increments should now always be smaller than right click
- previously this was not consistent for all types of buttons
- as before, CTRL may do smaller steps, SHIFT may do larger steps
- this change should apply to distance, colour, angle and scale
Find button for error triangles or points now selects all as expected
- previously only selected the first point or triangle in the list
I've had a look into this, found a possible reason for the crash and recreated a crash that matches your description.
It looks as if the code will fail (and crash, unpredictably) if there are more than 64 different materials in the model (when the subobjects are combined with the main model, which LFS does automatically).
I'll need to decide how to allow more materials, limit the number of materials, or both, as it is of course not acceptable for the program to crash.
Although I will do that, I must also say that I feel it's an excessive number of materials. Eric's most extremely detailed vehicle, the RB4, has reached 50 materials. Although I shouldn't be surprised that someone else's model exceeds 64 materials, as a programmer I feel this is too much for in game use and somehow you should reduce the number of materials. Maybe you can achieve the same results by either reducing the number of textures (e.g. by using cutouts on fewer, combined, texture pages) or reducing the number of different material settings in the 'cutout' mode?
I can't give any specific suggestions without seeing the model, but I have made a note to consider a fix/limit/warning/etc. Please let me know if the explanation makes sense (if I've described it properly and if you model really does have so many materials).
OK, I think that's exactly what Eric was talking about.
Please explain a bit more - I don't know what this means.
I think that will be: /pitreq repair [yes/no]
I think you are now talking about live settings? F11 menu? I understand this seems like a similar thing but I won't look at that for now.
You can look in the guide on the linked page, it is a pretend wet condition, drivers must pit and use road tyres if the rain comes (declared by the organiser). The cars are harder to handle so it's similar to real life, even if there is no actual rain.
Something Eric asked me about recently, combined with another thing I noticed regarding the E-challenge, makes me want to do a quick update.
Eric's suggestion is a keypress to cycle the F9 to F12 status screens.
My answer is something like a /status command.
How about: /status [none/F9/F10/F11/F12/next/prev]
So for Eric's request you would assign to an F key (and wheel button) the following text command: /status next
How it relates to E-Challenge: on this thread there are some scripts designed to make it easy to set pit instructions to change tyres, when conditions change to wet or dry.
But it is possible for these scripts to go wrong if you aren't careful as they rely on the starting conditions being correct. This is because they use left and right arrow key presses, which change things (e.g. tyres) relative to the current value.
They go into or out of the status screens with commands like /press F12 (which also has the problem that F12 is a toggle, so if you are already in that screen you would exit the screen instead of entering it.
So I was thinking this could be better if there were some very positive commands that don't rely on the current setting.
I was thinking of a command /pitreq, that could work like this:
/pitreq ftyre R2
/pitreq repair yes
/pitreq cancel
/pitreq rcamber -2
I hope you get the idea and I just thought I'd put that out there as I hope to do a quick job on it, and maybe someone thinks of something I haven't thought of.
I think the following /pitreq options are needed, though it's not fully considered yet.
fuel
tyrechange
repair
symmetric
ftyre
fcamber_l (aka fcamber if symmetrical)
fpressure_l (aka fpressure if symmetrical)
fcamber_r
fpressure_r
fwing
rtyre
rcamber_l (aka rcamber if symmetrical)
rpressure_l (aka rpressure if symmetrical)
rcamber_r
rpressure_r
rwing
It has gone down in 10 years, yes, as discussed a thousand times, due to so many things we can't discuss here and piracy too, But far more interesting is how it has gone up in the last 1.5 years. See the attachment, representing 600 weeks.
But calling it abandoned is just some fantasy which you want to believe in because it suits your narrative. To believe that, you have to ignore all our progress reports, everything we say, decide we are lying than make up your own version of reality. In fact I'm working about 10 hours a day and Eric is working loads too. There is a lot of progress. Is it as fast as anyone would like? No, but to suggest it is abandoned is just so absurd from my point of view.
The game has picked up so much, sales are up since 2021 when there was a serious problem, as stated. Piracy was bringing the game down. Now it's not. You are free to believe what you want but I'd appreciate it if you won't mope around here making up fantasies of doom and gloom and trying to paint that depressing picture.
You know, this thread is about how to improve attendance for scheduled events. The answer can't be, let's go back in time 10 years and change history. What threads are for is, to comment if you have anything to say on the matter. Not an invitation to spread feelings of doom and gloom.
Interesting thoughts that the new version might help with this, and even the thought of a slight rename with that version, so that journalists don't keep saying it's a 20 year old game and implying that the developers have vanished. Though there is a slight problem with that as it really is an ongoing project. When the 'big release' comes out there will still be some outdated stuff remaining that Eric and I still want to work on.
Anyway it's not a big deal, just slightly annoying to hear the same old crap which is just made up on the spot, or copied from other journos. Or maybe they are confusing it with some other old game, it does sound a bit like that. Probably the guy is quite young too as he appears to think that wheel support is something new, doesn't realise LFS had support for FF wheels long before 2002. But now I'm making up my own stuff.
Anyway nothing more important than the new version that we are still working hard on!
After a longer gap than usual there are a few things to report.
Soon after the last report, after fixing a few things that were sitting on lists, I added a new type of object that can be used in the track editor to connect up other objects more easily. Instead of the usual cross-sections connected by segments (with curves) this new system allows the simple addition of triangles. As if in the modeller, but between different cross-sections. It's hard to explain but it does simplify tasks by making it a lot easier to fill odd-shaped holes!
After my day of fixes on Fern Bay, Eric decided to have a quick go at it, really just fixes for the new lighting system. There were still some holes to fill, which are important for shadows, and he wanted to add some shine (specular effect) to the roads. He updated a few textures here and there in addition to the road surfaces but did the bare minimum of modelling. As stated before, there isn't time to bring Fern Bay up to the modern standard before the coming release, but it was certainly worth a few days tidying up.
After Eric sent me the update, I noticed a few remaining issues that I could improve with the use of new editor functions that I quickly coded. It is useful for me to spend a little time in the track editor because I often think of a few new functions or improvements to do.
Trying to get things finished can be a lengthy process! After the Fern Bay update we ended up taking on an extra task, almost by mistake. Eric wanted to update some of the layout objects which looked quite tired and old. His plan was just a few days brushing up a few objects. Quickly the task expanded and we started to make use of the new mapping configuration and monochrome colours system, that help maintain variety in the track editor, now extended to the layout objects. With a single object selected there can be several variations on the texture cutouts that are displayed. There was community involvement and we took on some of the ideas. There are definite benefits, so it was worth a week on the job. Even if that week turned out to be two weeks! We're near the end of layout updates for now!
Public thread about layout objects: https://www.lfs.net/forum/thread/101752
Eric and I have discussed the need to try to get to the release and only do what is necessary from now on. We want to do a lot of things but they can be done after the release.
On my side I have another day or two on layout functions, and there are some editor features to look at that could help Eric complete South City. Sometimes when buildings follow the edges of existing roads they can end up quite complex and bring up issues that can be made easier by certain new editor functions. I enjoy doing editor functions but of course, I am trying to get off graphics to finish the tyre physics and get to that public beta as quickly as possible.
Log of updates:
Layout marshals also needed to pick up lighting from lightmap (objects already do)
- marshals are done a different way and do a single lightmap reading when first drawn
Improved track editor function for setting height of multiple points
- also generally updated initialisation of text entry to the new style in a few places
Added a new type of surface that can be added in the track editor
- an extension of "section end triangles" but now can connect to other cross-sections
- as arbitrary triangles between track objects they can make it easier to fill holes
- turned out this is was a bit more work than expected in the track editor
- when objects can refer to others a lot of care must be taken with delete functions
Fix: track editor bug - surface properties were not updated correctly when changed
Fix: a physics surface debug display was not using the thread-safe copy of wheels
Fix: suspension diagram was also not yet updated to use thread-safe variables
Fix: time could move on up to 30 sec in track editor then car would catch up on exit
Eric sent a minor update of Fern Bay with specular lighting added to road textures
- other small updates as well including filling all the holes as seen from above
- although it's not a full update these are important fixes for the shadow system
- also improved a few textures around that needed brightening up in addition to shine
- the general effect is improved as you can see in the attached screenshots
I spotted a few remaining Fern Bay issues and went into the track editor to fix them
- changed/added editor functions that helped with searching/updating multiple objects
- a benefit of me spending time in editor is I sometimes come up with useful functions
Eric started to do a quick update on the layout objects that would take a few days
- it is not really the highest priority but seemed like a quick improvement at first
- job got a little bigger as we added support for selectable "mapping configurations"
- these, along with a colour selector, allow more variety without more object slots
- so we can have e.g. more signs or cone colours using the new improved objects
Discussion with Eric about the new world triangles hole filling system
- it can help fill holes in South City, either large holes out of town or small holes
- Eric showed me some of the challenging things at South City to finish in a good way
- looking at the real situations that come up, we thought of some helpful improvements
Worked on the updated (and new) layout objects
- asked community members if they had suggestions for a few useful objects
- some useful things came from that thread: https://www.lfs.net/forum/thread/101752
- using the new mapping configurations and monochrome colours, more variety is possible
- with a single object selected, multiple configurations can be chosen (e.g. letters)
- in the screenshot you can see most of the new objects but not showing all variations
Well there has also been a request to use the back of such boards as an advert slot allowing people to change it through AX_ADS1 image file, which Eric and I have not discussed yet.
A question about the paint letters (see attachment).
As with the letter and number boards, there are 3 objects with 16 slots each.
For the polystyrene tiles we have:
A-M SPACE . : N-Z # @ / 0-9 ( ) < > ^ v [last 4 are small arrows]
But the road paint has slightly different use.
1) no need for SPACE (does nothing). Eric suggests & which is commonly used on roads.
2) small arrows aren't appropriate, in real life they are twice as long as the letters, so we'll probably add some painted long arrows on a separate object.
That leaves the last 4 mapping slots free and I thought it would be best to ask what characters or character-sized symbols you might want in there.